Portable Biometric Identity on a Distributed Data Storage Layer

ABSTRACT

A distributed data storage layer supports biometric identification systems. The biometric identity system includes hardware and software improvements for capturing, retrieving, and verifying identity based on securely stored biometric data in the distributed data storage layer. As a result, the biometric identity system provides increased individual security and reliable identification.

PRIORITY CLAIM

This application is a continuation of and claims priority to U.S. patentapplication Ser. No. 16/008,717, filed on Jun. 14, 2018, which claimspriority to European Patent Office Application No. EP17306091.4, filedwith the French Patent Office on Aug. 23, 2017, which claims priority toEuropean Patent Office Application No. EP17305735.7, filed with theFrench Patent Office on Jun. 15, 2017. Each of these prior applicationsare herein incorporated by reference in their entireties.

TECHNICAL FIELD

This disclosure relates to securely storing and controlling access tobiometric identity.

BACKGROUND

Rapid advances in electronics and communication technologies haveresulted in newly emerging complex unforgeable transaction chainsimplemented on top of distributed data storage layers. Blockchains arean example of a distributed data storage layer. Improvements in thehardware and software implementations of the distributed data storagelayers, as well as their feature sets, will extend the distributed datastorage layers into new areas that provide, e.g., increased security andportability of data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an architecture for a distributed data storage layer systeminvolving trusted entities.

FIG. 2 shows a global network architecture for a service system.

FIG. 3 shows a global network architecture for a biometricidentification system in the context of providing services.

FIG. 4 shows an architecture for processing components of the biometricidentification system.

FIG. 5 shows a permissioned distributed data storage layer for identityverification for providing services.

FIG. 6 illustrates modes of communications between participants of thebiometric identification system.

FIG. 7 illustrates functions of participants of the biometricidentification system and types of information communicated between theparticipants.

FIG. 8 shows message flow between data platforms for generating digitalidentity and creating a distributed data storage layer identity index.

FIG. 9 shows message flow between data platforms for requesting identityauthentication and biometric identity verification.

FIG. 10 shows message flow between data platforms for renewing digitalidentity and updating a distributed data storage layer identity index.

FIG. 11 shows message flow between data platforms for generating digitalidentity and creating a distributed data storage layer identity indexwithout any personal identity device.

FIG. 12 shows message flow between data platforms for requestingidentity authentication and biometric identity verification without anypersonal identity device.

FIG. 13 shows an example application of a global biometricidentification system.

DETAILED DESCRIPTION

Distributed data storage layers (DDSL) remove a need for trustedentities because of a decentralized consensus mechanism. Blockchain isan example of such a distributed data storage layer. Authenticity ofdata elements (including transactions of many different types) recordedor inserted by participants into a DDSL are further facilitated viadigital signatures. The digital signatures may be based on asymmetricencryption techniques, including public/private key infrastructure. Thedata elements recorded in the DDSL, while being nearly unforgeable andunalterable, remain accessible to all participants of the DDSL via theirDDSL nodes (e.g., blockchain nodes). In particular, each participant,not necessarily a trusted entity, may decrypt and access any dataelement in the DDSL using a public key of the party who has digitallysigned the data element and inserted it into the DDSL. The traditionalDDSL technology thus does not inherently provide privacy with respect tothe recorded data elements. In reality, some data that are suitable forDDSL protection may be sensitive and private. For those types of dataand related applications, an enhanced DDSL is described that in oneaspect provides technical solutions for recording and verifying personalidentities.

Specifically, as shown in FIG. 1, a DDSL provides a trusted data storagelayer environment. Such a DDSL 110 may be termed a “permissioned DDSL”.In a permissioned DDSL, participating entities are trusted parties andthus may be allowed to access data elements that are of sensitive andprivate nature. The trust may be pre-established or pre-certified by atrust anchor 120. Typically, only pre-certified entities 130 mayparticipate in the permissioned DDSL and have access to the dataelements recorded in the permissioned DDSL 110. DDSL (such as ablockchain) is still distributed and public but permissioned (ratherthan a private storage layer).

The trust anchor 120 and the pre-certified entities 130 may participatein the permissioned DDSL 110 via corresponding DDSL nodes 140. Further,the trusted parties may be pre-certified with various levels of trust.Each level of trust may be associated with a predefined set of accessprivileges, which may include any combination of read or write and otheraccess rights optionally enforced through a use of smart contracts(e.g., for easing key backups and recovery) with respect to the dataelements in the permissioned DDSL 110. The permissioned DDSL nodes 140may be configured according to the level of trust associated with thecorresponding trusted entities. Entities with higher trust levels may,for example, have both read and write privileges and entities with lowerlevels of trust, however, may only have read privilege.

The certification and management of trusted entities 130 by the trustanchor 120 may be realized independent of the permissioned DDSL itself.To become a participant of the permissioned DDSL 110, for example, anentity may first establish trust within the permissioned DDSL via thetrust anchor based on the predefined registration and certificationprocess, rules and node implementation of the permissioned DDSL. Thedifferent levels of trust on the permissioned DDSL 110 may be determinedby the rules of a consortium of the permissioned DDSL, and may behandled by a trust management application. In some implementations,there may be multiple trust anchors for the permissioned DDSL system.

Such a permissioned DDSL system may be used to maintain data elementsthat are sensitive or are of private nature and should be onlyaccessible by trusted entities. For example, such permissioned DDSL maybe employed to manage personal identities. Personal identities are afoundation for various social and economic activities. Many servicesprovided by entities such as governmental agencies and financialinstitutions to individuals require identity verification. Personalidentification issued by governmental authorities is traditionallyprovisioned based on physical documents, such as driver licenses,passports, and other forms of portable identifications. Verification ofpersonal identities thus involves at least two aspects. In the firstaspect, the authenticity of the physical identity documents is examinedand verified (e.g., a passport is authenticate in that it is issued by alegitimate authority). In the second aspect, linkage between physicalidentity documents and the individuals holding the documents isverified. The traditional infrastructure of physical identities may beproblematic because both verification aspects above may be easilycompromised. For example, physical identity documents may be easilyfalsified, altered or tampered with, evading detection. Further, humanverification of linkage between a physical identity document and theperson holding it based on, e.g., photograph identity document, may beinaccurate.

The enhanced DDSL described below, in another aspect, supportsimplementations using a permissioned DDSL to store personal identityindexes, allowing certified trusted parties providing various social,economic and other services to verify authenticity of electronicpersonal identities carried in a portable electronic device (analogousto a passport) via the permissioned DDSL. The trust anchor 120 in thisparticular application would be, for example, an entity that creates,tracks, and updates personal identities in addition to managingcertification of trusted entities 130. Alternatively, an identityprovider and a trust anchor may be separate entities. In someimplementations, there may be multiple identity providers. Further,biometrics of individuals may be captured and maintained by an identityprovider and, for services requiring a high-level of security, thelinkage between the electronic personal identities and the individualsholding it may be further verified based on biometric matching. In oneimplementation, such biometric verification processed may be facilitatedby the permissioned DDSL but performed off-DDSL, as will be described inmore detail below.

The enhanced DDSL provides technical solutions to the difficultchallenges of establishing a unique identity, tracking, updating, andverification using portable electronic identities, permissioned DDSL,and biometrics. Some of the technical benefits include: enhancedidentification of individuals, enhanced security of access to biometricdata, and more secure permissioned access and use of personal identitiesand biometric data. Even though the disclosure below use the applicationcontext of personal identity as an example, the underlying principles ofthe permissioned DDSL are not limited to the personal identity context.Rather, they may be used in other contexts and applications involvingsensitive data elements that are not suitable for processing bycompletely public and non-trusted DDSL platforms. Further, in theimplementations below, the permissioned DDSL only stores personalidentity indexes, which may not be as sensitive as data such asbiometric and/or biographic information of individuals. As such, theimplementations below may be modified, without deviating from theoverall principles of this disclosure, to employ a non-trusted DDSLinfrastructure rather than a permissioned DDSL, with other aspects ofthe disclosure remaining applicable.

FIG. 2 shows a global service network architecture 200 in which theprovision of services to individuals requires verification of personalidentities. Connected through the global network architecture 200 areservice platforms, e.g., the service platforms 202, 204, 206, and 208,that provide a range of identity-based services (“services”) toindividuals 230. As examples, the services may include but are notlimited to identity registration and renewal services by certifiedauthorities (acting as identity providers); government services, e.g.,border control, benefit enrollment, or police services; medicalservices, e.g., hospital admissions or doctor diagnostic portals; orprivate financial and business services, e.g., banking services orretail sales. Rendering of services provided by the service platforms202-208 may involve either identity registration or identityverification (220) of the individuals 230. The service platforms 202-208may be located in any geographic region, e.g., the United States,Europe, or Asia. The service platforms 202-208 may be connected vianetworks 210. The networks 210 may include private and public networksdefined, for example, over any pre-determined or dynamic Internetprotocol (IP) address ranges.

As an example implementation, FIG. 3 shows a specific global servicenetwork architecture 200 including service platforms A and B connectedvia the networks 210. Service platforms A and B may each include one ormore servers (310 and 320, alternatively referred to as back ends), oneor more service stations (314 and 324), and one or more service nodes(312 and 322). The service platforms A and B may each be global. Assuch, the servers 310 and 320, the service stations 314 and 324, and theservice nodes 312 and 322 may be centralized or distributed in anygeographic region. The distributed servers, service stations, andservice nodes of the service platforms A or B may be connected viaprivate or virtual private networks as part of the networks 210. Theservice stations 314 and 324 provide interfaces for an individual toobtain services from the service platforms A and B. The servers 310 and320 provide processing, storage, identify verification, and otherfunctions needed before, during, and after provision of the services.The service nodes 312 and 322 form a global identity verification system330 among the service platforms. In one implementation, the globalidentity verification system 330 may be based on a permissioned DDSL110. Accordingly, the service nodes 312 and 322 may be implemented asDDSL nodes of the permissioned DDSL 330/110.

FIG. 4 shows an example implementation of the servers 310 and 320, theservice stations 314 and 324, and service nodes 312 and 322 of FIG. 3,as computer systems 400. Computer systems 400 may include communicationinterfaces 402, system circuitry 404, input/output (I/O) interfaces 406,storage 430, and display circuitry 408 that generates machine interfaces410 locally or for remote display, e.g., in a web browser running on alocal or remote machine. The machine interfaces 410 and the I/Ointerfaces 406 may include GUIs, touch sensitive displays, voice orfacial recognition inputs, buttons, switches, speakers and other userinterface elements. Additional examples of the I/O interfaces 406include microphones, video and still image cameras, headset andmicrophone input/output jacks, Universal Serial Bus (USB) connectors,memory card slots, and other types of inputs. The I/O interfaces 306 mayfurther include magnetic or optical media interfaces (e.g., a CDROM orDVD drive), serial and parallel bus interfaces, and keyboard and mouseinterfaces.

The communication interfaces 402 facilitate connection of the computers400 to the networks 210 (of FIGS. 2 and 3) and may include wirelesstransmitters and receivers (“transceivers”) 412 and any antennas 414used by the transmitting and receiving circuitry of the transceivers412. The transceivers 312 and antennas 314 may support Wi-Fi networkcommunications, for instance, under any version of IEEE 802.11, e.g.,802.11n or 802.11ac. The communication interfaces 402 may also includewireline transceivers 416. The wireline transceivers 416 may providephysical layer interfaces for any of a wide range of communicationprotocols, such as any type of Ethernet, data over cable serviceinterface specification (DOCSIS), digital subscriber line (DSL),Synchronous Optical Network (SONET), or other protocol.

The system circuitry 404 may include hardware, software, firmware, orother circuitry in any combination. The system circuitry 404 may beimplemented, for example, with one or more systems on a chip (SoC),application specific integrated circuits (ASIC), microprocessors,discrete analog and digital circuits, and other circuitry. The systemcircuitry 404 is part of the implementation of any desired functionalityrelated to the provision of services and registration, renewal,authentication, and verification of identities. As just one example, thesystem circuitry 404 may include one or more instruction processors 418and memories 420. The memories 420 stores, for example, controlinstructions 424 and an operating system 422. In one implementation, theinstruction processors 418 executes the control instructions 424 and theoperating system 422 to carry out any desired functionality related tothe provision of services and registration, renewal, authentication, andverification of identities. The control parameters 424 provide andspecify configuration and operating options for the control instructions426, operating system 422, and other functionality of the computersystems 400.

The storage 430 may be used to store various initial, intermediate, orfinal data for the provision of services and registration, renewal,authentication, and verification of identities in computer systems 400.For example, computer systems 400 for implementing servers for providingregistration and renewal of identities may maintain in storage 430biographic, biometric data, and corresponding identity information 432for individuals. Service nodes (such as the DDSL nodes 312 and 322 ofFIG. 2) may store DDSL copies 433 of the permissioned DDSL 110 as partof the global identity verification system 330 of FIG. 3 in the form ofa permissioned DDSL.

Returning to FIG. 3, access to the permissioned DDSL system 330/110 maybe limited only to service providers of service platforms havepre-established trust, unlike a traditional public and non-trusted DDSLsystem that allows any entity to participate without certification andrelies purely on the consensus mechanisms implemented in the DDSL fortrust. Service providers may be pre-certified and participate in theDDSL system 330/110 at various predefined levels of trust. Eachcertified service provider participates in the DDSL system 330/110 viaits DDSL node. DDSL nodes of different trust levels may be configuredwith corresponding predefined functionalities for accessing thepermissioned DDSL. For example, a node of higher trust level many bepermitted to both read from and write to the permissioned DDSL. A nodeof lower trust level, however, may be only permitted to read from thepermissioned DDSL.

FIG. 5 shows the permissioned DDSL 110 of FIG. 1 employed in theapplication context of personal identities. An identity provider 520 maybe a special type of service provider (for providing identityregistration services) and may or may not act as the trust anchor 120 ofFIG. 1. Likewise, the trusted service providers 530 may be examples ofthe trusted entities 130 pre-certified by the identity provider 520. Theidentity provider 520 and the trusted service providers 530 mayparticipate in the permissioned DDSL 110 via DDSL nodes 140 and 150. Theparticipants of the permissioned DDSL 110 in the example implementationof FIG. 5 thus involve two general levels of trust. For example, serviceproviders such as the United Nations may act as an identity provider 520responsible for unique identification/registration and forpre-certification of other trusted service providers 530. Such specialservice provider may thus be of the highest level of trust. Identityproviders may be general or specific. A general identity provider mayprovide identity to the general public. A specific identity provider mayprovide identity to individuals of particular demographic, geographic,and other scopes and context. For example, United Nations may act as anidentity provider for refugees. The term identity provider may bealternatively referred as identity custodian in that it is not meant tobe equivalent to just a single authority for providing identity foreveryone. The other service providers 530 may be of lower level of trustand may include, for example, various governmental agencies and banks.The service nodes 140 and 150 acting as DDSL nodes may be configured inaccordance of various levels of trust. Even though FIG. 5 separatelydescribes an identity provider and a trusted service provider inrelation to the permissioned DDSL, a trusted entity may act as both anidentity provider and trusted service provider (with appropriate trustlevel). In a sense, the provision of identity (by an identity provider)is one type of trusted services. There may be multiple identityproviders and trusted service providers certified by the trust anchordistributed throughout the system.

The general two-level permissioned DDSL of FIG. 5 is merely an example.Other implementations are contemplated. For example, the predefinedlevels of trust may include three levels, e.g., high, medium, and low.Entities acting as identity providers such as United Nations and otherentities such as European Union, various central governments, andFederal Bureau of Investigation may be provided with high level oftrust. Service providers such as banks, municipal governments, and somecountries may be provided with medium level of trust. Other serviceproviders such as merchants and retail stores may be provided with lowlevel of trust.

The participating nodes of the permissioned DDSL 330/110 may each storea copy of the permissioned DDSL (e.g., a copy of the blockchain). Eachcopy of the DDSL contains linked data blocks of data elements. Dataelements are added into the DDSL by participating nodes with writepermission. Each data element is associated with an index (also referredto as a DDSL identifier, a DDSL index, a block index, a blockidentifier, a data element index, or a data element identifier) foridentifying the data element in the DDSL. As such, the DDSL may bequeried for specific data elements without having to traverse the entirelinked data blocks. The data elements added by the DDSL nodes may betransactions related to personal identities. For example, a data elementmay be an identity index for an individual, or may be a transaction thatinvalidates an earlier obsolete identity index (e.g., an earlieridentity index that has been renewed or updated and is thus renderedobsolete). The format and contents of the data elements in thepermissioned DDSL maybe predefined with one example implementationdiscussed in detail below.

Authenticity of the data elements in each data block of the permissionedDDSL may be achieved using cryptographic technologies. For example,digital signature based on public and private key cryptography may beused to ensure that a data element to be inserted into the DDSL issigned by and originates from its proclaimed submitting entity. Inparticular, each entity participating in the DDSL system and who wishesto store data elements in the DDSL may be in possession of a private keythat is kept secret at all times (e.g., managed by a Hardware SecuredModule, or HSM). A public key associated with the private key (e.g.,mathematically) may be derived from the private key and may be madepublicly available (e.g., managed by a Public Key Infrastructure, orPKI). When a participating entity wishes to store a data element in theDDSL, the entity may first digitally sign the data element using itsprivate key before the data is submitted for insertion in thepermissioned DDSL. The signed data element may be decrypted by anyonehaving access to the permissioned DDSL and the public key of thatentity. Any tampering of the signed data will results in unreadable datawhen being decrypted using the public key. As such, signing using theprivate key represents a digital signature of the data element by theentity and any tampering of the signed data is easily detected.

Thus, the identity provider and trusted service providers participatingin the permissioned DDSL may be each be associated with a set of privateand public keys. The private keys may be used by the participatingentities to sign data elements to be inserted into the permissionedDDSL. The public keys may be used by others to decrypt data elementsinserted into the permissioned DDSL. For example, the identity providernode may submit a data element associated with identity index of aparticular individual into the permissioned DDSL 230 by signing the dataelement with its private key. Other certified trusted service providersmay locate the data element in the permissioned DDSL using a dataelement identifier for the data element and decrypt the data elementusing the known public key of the identity provider during the processof conducting identity verification.

The permissioned DDSL 330/110 may further implement otherfunctionalities for detecting tampering of the recorded data elements.As such, the data elements inserted into the permissioned DDSL may beprotected from being altered at a later time. The International PatentApplication No. PCT/CN2017/083597 filed with the State IntellectualProperty Office of China on May 9, 2017 by the same Applicant provides adetailed description of these functionalities. In addition, a consensusmechanism may be implemented among the participating DDSL nodes toprevent any of the participating nodes from inserting uncertified orunauthorized identity index data elements.

FIG. 6 illustrates a more detailed implementation of modes ofcommunication between an individual (230, alternatively referred to as“user”), an identity provider (610), a trusted service provider A (620),and a trusted service provider B (630). The individual 230 may beassociated with a portable identity device in the form of, e.g., amobile phone 602 or smart card 604, collectively referred to as a mobileidentity wallet 606. The mobile identity wallet 606 may be used to storedigital identity of the individual 230, analogous to an electronicpassport (ePassport). The identity provider 610 is responsible forproviding identity registration, renewal, and management. The identityprovider 610 may provide its functionalities via an identity serviceplatform including one or more identity provider stations 614, one ormore identity provider servers 612, and one or more identity providerDDSL nodes 616. Trusted service providers A (620) and B (630) may eachinclude one or more service provider stations, service provider servers,and service provider DDSL nodes, shown in FIGS. 6 as 622, 624, 626, 632,634, and 636.

The DDSL nodes 616, 626, and 636 form the permissioned DDSL system330/110. Communications between the DDSL nodes 616, 626, and 636, aspart of the functionality of the permissioned DDSL 330/110 may bereferred to as DDSL communications, as shown by the solid lines 660 inFIG. 6 connecting the DDSL nodes 616, 626, and 636 of the permissionedDDSL 330/110. Public keys for various DDSL nodes may be managed by thePublic Key Infrastructure (PKI) 670. The user 230 may interact with theidentity provider 610, the trusted service providers A and B (620 arid630) via service stations 614, 624, and 634, for registration andrenewal of identity, and for obtaining various services that requiresidentity verification. In one implementation, the user 230 may not be aparticipant of the permissioned DDSL. As such, the communicationsbetween the user 230 and the service stations 614, 624, and 634 may beoff-DDSL, as shown by the dotted lines 650 in FIG. 6.

In addition, data elements in the permissioned DDSL 330/110 may containlimited information sufficient for functioning as identity indexes forthe purpose of authenticating identity, as will be described in moredetail below. Other information related to identity verification may befurther communicated between the servers of the identity provider 610and service providers 620 and 630. These other communications forinformation not contained in the permissioned DDSL, may be madeoff-DDSL, as indicated by the dotted line 650 between the server 632 ofthe trusted service provider B (630) and the server 612 of the identityprovider 610. Some trusted service providers, such as trusted serviceprovider A (620), may only need to communicate with the user 230directly and with the permissioned DDSL 330/110 for authentication ofattestations in, or indexed by, the mobile identity wallet 606. In thatcase, the server 624 may not need to have off-DDSL communications withservers of the identity provider 610 and other trusted service providerssuch as 630.

FIG. 7 illustrates, as one exemplary implementation, functionalities ofthe mobile identity wallet 606, the identity provider 610, and thetrusted service provider 620/630 of FIG. 6, as well as exemplary typesof information communicated via the permissioned DDSL 330/110 (660) orcommunicated off-DDSL (650). Similar to FIG. 6, dashed communicationlines labeled as 650 represent off-DDSL communications and solidcommunication lines labeled as 660 represent communication with thepermissioned DDSL 330/110.

In the specific implementation of FIG. 7, the user 230 may register withthe identity provider 610 by providing biographic data and by allowingthe identity provider to collect biometrics information (702). Thebiometrics collected from user 230 may include but are not limited tofingerprint, facial image, iris image, voice samples, DNA sequences,palm veins, and palm print. The mobile identity wallet 606 belonging tothe user 230 may store users profile data, such as biographic data. Themobile identity wallet 606 may further be responsible for generating apair of private and public keys for the user. Even though the user 230does not have privilege to write to the permissioned DDSL in someimplementations, the private key for the user may be used to digitallysign various off-DDSL communication messages from the user to theidentity provider and to other trusted service providers. For exampleand as will be described in more detail later, the user may providedigitally signed consent for the trusted service provider 620/630 toaccess biometric or biographic information of the user stored with theidentity provider (706). Such a consent may be signed using the privatekey of the user. For another example, an identity attestation signed bythe identity provider to be described in more detail later may befurther signed by the user using the user's private key. The user'sprivate key may be managed by a HSM component included in the mobileidentity wallet 606.

The mobile identity wallet 606 may additionally be responsible forstoring the identity attestation signed by both the identity provider610 using the private key of the identity provider and the user by theuser's private key after the identity provider creates an identity andthe corresponding identity attestation for user 230. The signed identityattestation in the mobile identity wallet 606 forms the main form ofidentity to be used for identity verification by the trusted serviceprovider 620/630. The mobile identity wallet 606 may further store thedata element identifier associated with the identity data element (theidentity index) for the user in the permissioned DDSL 330/110. Asdiscussed below, this data element identifier is generated by theidentity provider 610 when inserting the identity data element for theuser into the permissioned DDSL and may be signed by the identityprovider using its private key.

Continuing with FIG. 7, the identity provider 610 may receive biographicdata of the user and the user public key at a service station of theidentity provider 610. The identity provider 610 may further collect aset of biometrics from the user. The identity provider 610 isresponsible for secured storage and removal of the user biographicand/or biometric information in conformance with the privacy constructsof the solution. The set of biometrics collected from user 230 mayinclude but are not limited to fingerprint, facial image, iris image,voice samples, DNA sequences, palm veins, and palm print. The set ofbiometrics to be collected by the identity provider may vary widelydepending on the provider, and different providers may collect differentcombinations of biometric data corresponding to the underlying businesscase(s). The size of the biometrics set may be predetermined based onthe size and diversity of population the identity provider is expectedto manage. A representative set of biometrics may be predetermined suchthat the predetermined set of biometrics can be used to uniquelyidentity each individual within the population even when someindividuals may lack certain biometrics (e.g., some individual may lackrecognizable finger print either due to lost fingers or due to fingerwear as a result of prolonged heavy manual labor). A larger set ofbiometrics may be gathered for a larger population set. For example, fora small population set, only fingerprint may be sufficient foreffectively identifying each individual in the population. However, fora large population, fingerprint alone may not be sufficient and acombination of fingerprint, facial image and even other biometrics maybe required to uniquely identify each person in the population.

The identity provider 610 is further responsible for de-duplicating theset of collected biometrics that may have already been registered inorder to prevent double registration. The identity provider 610 isfurther responsible for generating a digital unique identificationsequence (DUIS) for the user 130. The DUIS may be any sequence ofsymbols. For example, the DUIS may be a numerical number contained apredetermined number of digits. Alternatively, the DUIS may be a mixedsequence of numerals and alphabets. In one implementation, the DUIS maybe generated by the identity provider 610 as a unique random numericalnumber. In another implementation, the DUIS may be generated by seedingfrom the set of measure biometrics data. The seeding process may bedeveloped such that preferably a same unique DUIS is generated from setsof biometrics independently measured from a particular user. Theidentity provider 610 may further generate an identity data element tobe inserted into the permissioned DDSL 330/110. The data element mayinclude, for example, the public key for the user, and a token generatedfrom the DUIS. Accordingly, the identity provider 610 may additionallybe responsible for generating a token of the DUIS. A token rather thanthe DUIS is inserted into the permissioned DDSL for an added level ofsecurity because other trusted service providers may then only be ableto access the token via the permissioned DDSL rather the DUIS. Tomaintain such security for the DUIS, it is preferable that the DUIScannot be backtracked easily from the token. As such, the generation ofthe token from the DUIS may be implemented suing a one-way function,such as a hash function and the like. The data element may then besigned by the identity provider 510 using its private key and insertedinto the permissioned DDSL (720). The data element identifier for theinserted data elements is tracked by the identity provider and the dataelement identifier may be signed by the identity provider using itsprivate key. The signed data element identifier for the inserted dataelement may be provided to the mobile identity wallet 606 (704). Theidentity provider 610 may further maintain a mapping between the DUIS,the token, the data element identifier of the data element associatedwith the token and DUIS, and the biographic and/or biometric informationsecurely stored by the identity provider for the user 230. Such amapping, for example may be stored in the data storage 430 of FIG. 4 forthe identity provider 610.

The identity provider 610 is further responsible for creating andsigning the identity attestation of identity for the user 230. Theattestation may simply be a statement by the identity provider that ithas verified the user identity physically. The identity provider maysign the attestation using its private key. In one implementation, theidentity attestation may include a set of attribute-level verification,e.g., name and date of birth. The attestation may further containattribute level biometrics information, i.e., the type of biometricsinformation of the user that the identity provider tracks. Theattestation preferably may not contain actual personal identifiableinformation (P11). The attestation signed by the identity provider 610may be provided to the mobile identity wallet 606 of the user 230 (704).As discussed above, the attestation signed by the identity provider andreceived at the mobile identity wallet may be further signed by themobile identity wallet using the private key of the user.

Continuing with FIG. 7, the trusted service provider 620/630 receivesrequest for service from user 230 (706). The trusted service provider620/630 may further receive the doubly signed identity attestation anddata element identifier (which may be signed by the identity provider)of the user data element (identity index) in the permissioned DDSL fromthe mobile identity wallet for verifying the authenticity of theidentity attestation (706). The trusted service provider 620/630 mayadditionally receive a signed consent to read and access biographicand/or biometric data of the user if further verification of identity isdesired (i.e., verification that the mobile identity wallet and theidentity attestation stored therein belongs to the user holding themobile identity wallet) (706). The trusted service provider 620/630 mayperform the verification of the authenticity of the identity attestationby accessing the permissioned DDSL 330/110 using the data elementidentifier from the mobile identity wallet (730). The trusted serviceprovider 620/630 may further perform verification of the user biometricsand biographic information by capturing physical biometric measurementsfrom the user (706) and communicate with the identity provider 610 forverification (710).

In the implementations of FIGS. 6-7 above, the functions of the identityprovider 610 and trusted service providers are described separately. Inother alternative implementations, a trusted entity may be both anidentity provider and a trusted service provider. As such, a trustedentity may perform a mixture of any of the functions of an identityprovider and a trusted service provider. For example, a trusted serviceprovider may act as an identity provider and thus may create and signidentity attestation for users.

FIG. 8 shows in more detail an exemplary logic flow 800 for establishingan identity for a user. Biographic and biometric data are first capturedby the identity provider station 514 (802 and 804). The identityprovider station communicates with the identity provider server 612 forrequesting enrollment of the user (806). The identity provider server612 performs biometric deduplication upon receiving the enrollmentrequest (808). The identity provider server 612 then sends thededuplication results to the identity provider station 614 (810). In themeanwhile, the mobile identity wallet 606 of the user proceeds togenerate the private/public key pair for the user (812). The mobileidentity wallet 606 may then prepare and securely send the generatedpublic key to the identity provider station 614 (814 and 815). Thesending of the public key may be based on Quick Response (QR) code. Assuch, the mobile identity wallet 606 may first prepare the user publickey into a OR graphic format (814) and then communicate the QR code ofthe user public key to the identity provider station 614 (815). Thecommunication of the OR code may be accomplished by a OR scanner of theidentity provider station 614. Specifically, the scanner of the identityprovider station 614 may read the QR code displayed on the mobileidentity wallet 606 of the user.

The identity provider station 614 may then send the user public key tothe identity provider server 612 with a request to create a DUIS for theuser (816). In response, a DUIS is generated by the identity providerserver 612 (818). The identity provider server 612 then sends thegenerated DUIS to the identity provider DDSL node 616 (819). Theidentity provider DDSL node 616 then generates a token from the DUIS(820) and prepares to insert a data element containing the public key ofthe user and the token generated from the DUIS for the user into thepermissioned DDSL 330/110. Alternatively, the token may be generated bythe identity provider server 612 and communicated to the identityprovider DDSL node 616. A data element identifier for identifying thedata element in the permissioned DDSL is created by the identityprovider DDSL node 616 (822) and the data element is signed using theprivate key of the identity provider and inserted into the permissionedDDSL (824). The identity provider DDSL node further sends the token andthe data element identifier of the inserted data element to the identityprovider server 612 (826). The identity provider server 612 then mapsthe received token and data element identifier to the corresponding DUIS(828) and stores the mapping.

The identity provider server 612 then informs the identity providerstation 614 of the completion of insertion of data element as anidentity index of the user into the permissioned DDSL (830). Theidentity provider station 614 then proceeds to create an identityattestation (832). The identity attestation may be referred to asattestation. The attestation and the data element identifier for theinserted data element is then signed using the private key of theidentity provider and sent to the mobile identity wallet 606 of the user(836). The identity provider station may further sign user biographicdata and or biometric data (captured in 802 and 804) using the privatekey of the identity provider and send it to the mobile identity wallet606 of the user along with the signed identity attestation (836). Thecommunication of the identity attestation from the identity provider 610to the mobile wallet 606 may be performed using any secure communicationprotocol. The mobile identity wallet 606 receives and stores theidentity data including the signed attestation, the signed data elementidentifier for the identity data element for the user inserted in thepermissioned DDSL, and optionally the signed biographic data and/orbiometric data (838). In one alternative implementation, the dataelement identifier may not need to be signed by the identity providerusing its private key. In that implementation, the mobile identitywallet may store the data element identifier without any digitalsignature. Before storing the received attestation, the mobile identitywallet 606 signs it using the private key of the user (838). As such,the attestation may be doubly signed and stored in the mobile identitywallet. In an alternative implementation, the mobile identity wallet mystore the attestation only signed by the identity provider but sign theattestation when providing it to a service provider for identityauthentication and verification.

By the implementation of FIG. 8, identity of a user may be registeredand created by the identity provider. The user may be uniquelyidentified by a DUIS. The public key for the user and the tokengenerated from the DUIS are stored by the identity provider in thepermissioned DDSL. Such a data element is protected from being alteredby the digital signature of the identity provider and the consensusmechanism inherent to the permissioned DDSL. The captured biometricand/or biographic data, however, is not stored in the permissioned DDSLand not directly accessible by the participants of the permissionedDDSL. The biometric and/or biographic data is securely stored by theidentity provider.

FIG. 9 illustrates an exemplary logic flow that a biometric identitysystem running on a DDSL may implement for the user to obtain a servicefrom a service provider requiring identity verification. The firstportion of FIG. 9 indicated by 900 illustrates a logic flow forauthentication by the service provider that the digital identity (e.g.,the attestation) carried in the mobile identity wallet 606 was issuedand attested to by the identity provider 610. The second portion of FIG.9 indicated by 901 illustrates a logic flow for further verification ofthe biometric and/or biographic information of the user. As previouslydiscussed, this second portion helps verify that the mobile identitywallet belongs to the individual holing the mobile identity wallet.

For the first portion of authentication 900, the user holding the mobileidentity wallet 606 may approach a service provider station 634 forobtaining service. The user may use the mobile identity wallet 606 topresent to the service provider station 634 identity presentation datasuch as identity attestation signed by the identity provider and theuser and the data element identifier (either signed by the identityprovider or unsigned) for the identity index data element for the userin the permissioned DDSL (902 and 904).

The service provider station 634 receives the doubly signed attestationand the signed or unsigned data element identifier (906). The serviceprovider station 634 may then send the data element identifier anddoubly signed attestation to the DDSL node 636 of the service forauthentication (908). If the data element identifier was not signed bythe identity provider, the service provider DDSL node 636 may directlyuse the unsigned data element identifier to look up the correspondingidentity index data element in the permission DDSL (910). In the casethat the data element identifier was signed by the identity provider,the service provider DDSL node 636 may first use the public key of theidentity provider to decrypt the signed data element identifier and thenuse the decrypted data element identifier to look up the correspondingidentity index data element in the permission DDSL (910). The serviceprovider server or DDSL node 632/636 may then use the public key of theidentity provider to decrypt the corresponding identity index dataelement located and identified from the permission DDSL to obtain thepublic key of the user (912). For authentication of the attestation(914), the public key of the user may be used to decrypt the attestationsigned by the user to obtain attestation signed by the identityprovider. The attestation signed by the identity provider may then befurther decrypted by the service provider server or DDSL node 632/636using the public key of the identity provider. As such, the attestationmay be read and analyzed by the service provider server or DDSL node632/636 to complete the authentication 914 that the content of theidentity attestation was indeed signed by the identity provider andsigned by the user. The authentication result is sent to the serviceprovider station 634 and the mobile identity may be accepted (916).Functionalities of the service provider other than accessing thepermissioned DDSL may be performed by the service provider server 632rather than the service provider DDSL node 636.

The logic flow 900 of FIG. 9 above authenticates that the mobileidentity wallet 606 contains a valid identity attested by the identityprovider. If the service provider desires to further verify that themobile identity wallet 606 belong to the person holding the mobileidentity wallet, logic flow shown in 901 of FIG. 9 may be performed.Specifically, the service provider station 634 may request permissionfor further verification of biographic and/or biometric information(920). Upon such a request, the user may give permission via the mobileidentity wallet 606 to the service provider station to validatebiographic and/or biometric data (922). The permission may be providedin the form a consent and the consent may be signed by the user usingthe private key of the user (924). The signed consent may be sent fromthe mobile identity wallet 606 to the service provider station 634 (926)and further sent to the identity provider server 612 (928). The identityprovider server 612 validates the user consent (930) by checking thedigital signature on the consent by the user and confirm validity of theconsent (931). Upon confirming the validity of the user consent, theservice provider station 634 may send user biographic data to theidentity provider server for verification (932). The verificationprocess by the identity provider server 612 may involve comparingreceived biographic data with the biographic data stored in the identityprovider server for the user (934). Further, the service providerstation may physically capture the biometric information of the user(936) and then send the captured biometric data to the identity providerserver 612 (938). The identity provider server then validates thebiometric information by comparing the received biometric informationcaptured by the service provider station with the biometric informationstored in the identity provider server for the user (940). Thevalidation result may then be sent to the service provider server 632and station 634 (942). In another implementation, the identity providerserver, after receiving the user consent, may provide requestedbiometric information so that the service provider may compare thecapture biometric information locally.

In one alternative implementation, the validation may process may bedone without the identity provider, if the user's biographic and/orbiometric data, signed by the service provider, was sent to and storedin the mobile wallet of the user (see, 836 of FIG. 8). In suchsituation, once the user give consent, the service provider may, forexample, decrypt the biometric data in the mobile wallet of the userusing the public key of the identity provider, and compare the decryptedbiometric data with biometric data that the service provider capturesfrom the user.

The user consent generated at step 924 may contain restriction for thebiographic and/or biometric verification. The consent, for example, mayonly be given to individual biographic data elements. In anotherimplementation, the consent may restrict the type of biometric databeing taken by the service provider. The consent may further specify anexpiration time of the consent. As such, the identity provider wouldonly perform validation of biographic and/or biometric data if taken andsent by the service provider to the identity provider before theexpiration time. A protocol may be pre-established for the user consentsuch that the consent can be properly formulated by the mobile identitywallet 606 and correctly interpreted and implemented by the serviceprovider 610.

This second verification process 901 of FIG. 9 does not directly involvethe permissioned DDSL. Rather, the verification is performed off-DDSL bythe identity server. Specifically and as described above, the identityprovider server 612 receives the biographic and/or biometric datacaptured by the service provider station 634, and compare the biographicand/or biometric data with the information stored in the identityprovider server under the DUIS corresponding to the token contained inthe user identity index data element obtained from the permissionedDDSL. A match would verify that the mobile identity wallet belongs tothe user holding it. The verification outcome may be furthercommunicated from the identity provider server 612 to the serviceprovider off-DDSL (942).

After enrollment of user identity with the identity provider, it may berenewed periodically, similar to ePassport renewals. Renewals ofidentity may be necessitated by gradual change of biometriccharacteristics of a person as they age. Such changes may be morepronounced at a younger age. Accordingly, the frequency of identityrenewals may be higher for younger users. For example, identity may berenewed every 10 years for adults and every 5 years for children.Further, identity of a user may need to be replaced in the event thatthe mobile identity wallet belonging to the user is lost or stolen. Therenewal process may involve an identity update with the identityprovider and a corresponding update of the identity index data elementin the permissioned DDSL.

FIG. 10 shows an exemplary logic flow 1000 for identity renewal that abiometric identity system running on a DDSL may implement. Inparticular, the user may approach the identity provider station 614,either with an existing mobile identity wallet 606 for identity renewalor with a new mobile identity wallet 606 for identity replacement. Theidentity provider station first captures biographic and/or biometricdata from the user (1002 and 1004). The biographic and/or biometric dataare then sent to the identity provider server 612 (1006). The identityprovider server 612 then searches its identity data store and finds anidentity having matching biographic and/or biometric information (1008).The DUIS for the matching identity is then returned to the identityprovider station 614 (1010). The user then generates a new pair ofpublic and private keys on the mobile identity wallet 606 (1014). Thenew public key is sent to the identity provider station 614 via, forexample, OR code (1016). The identity provider station 614 then sendsthe new public key for the user with a request to update identity of theuser to the identity provider server 612 (1018).

Continuing with FIG. 10, the identity provider server 612 further sendsthe new user public key to the identity provider DDSL node 616 (1020)for updating the DDSL identity for the user (1022). The updating of theDDSL involves writing a new identity index data element containing thenew user public key and the tokenized DUIS. It is preferable that theDUIS for the user does not change and remains unique for this particularuser. The token for the DU IS may remain the same as the old token.Alternatively, a new token may be generated from the DUIS for the user.The new identity index data element is signed using the private key ofthe identity provider and inserted into the permission DDSL 330/110 withan updated data element identifier. A second new data element may alsobe written to the permission DDSL (1028). This second new data elementmay be a record showing that the old identity data element with the olddata element identifier has been updated and has become invalid, andthat the new identity of the user is recorded in the identity index dataelement having the updated data element identifier. This second new dataelement may be inserted into the permissioned DDSL 330/110 with its owndata element identifier. Both the updated data element identifier forthe new identity index data element and the data element identifier forthe second new data element for invalidation of the old identity arereturned to the identity provider server 612 (1024 and 1026). Theidentity provider server 612 may then update mapping between the DUIS,the data element identifiers, and the tokens (both the old one and newone if regenerated from the DUIS during identity update) for the user(1030).

Still continuing with FIG. 10, the identity provider server 612 furtherforwards the updated data element identifier for the new identity indexdata element in the permissioned DDSL (the data element recording thenew user public key) to the identity provider station 614 (1032). Inresponse, the identity provider station 614 generates an updatedidentity attestation for the user (1034), signs it, and sends ittogether with the updated data element identifier signed by the identityprovider to the mobile identity wallet 606 of the user (1036). Themobile identity wallet 606 receives and securely stores the updated dataelement identifier and the updated attestation (1038). The mobileidentity wallet 606 signs the attestation before storing it. As such,the attestation may be doubly signed (by both the identity provider andthe user). Alternatively, the identity attestation may be stored by themobile identity wallet 606 unsigned by the user and it may be signedwhen being provided to a service provider for identity verification. Theupdated data element identifier for the new identity index data elementmay be signed by the identity provider using its private key. In onealternative implementation, the updated data element identifier may notneed to be signed by the identity provider using its private key. Inthat implementation, the mobile identity wallet may store the updateddata element identifier without any digital signature.

In some situations, the user may desire to update biographic and/orbiometric data with an identity provider and update the signedbiographic and or biometric data in the mobile identity wallet. Suchupdate may be achieved using various components discussed above in FIGS.8-10. For example, the user may approach an identity provider station,and after authentication by the identity provider, via the attestationauthentication procedure discussed above and by capturing userbiographic and/or biometric data at the provider station and compare itto the recorded biographic and/or biometric data (collected when theuser registers), the user may be allowed to provide updated biographicand/or biometric data to the identity provider. For example, the usermay update biographic information by attestation authenticationprocedure and by biometric authentication procedure (e.g., the identityprovider station captures biometric information and compare the capturedbiometric information to previously stored biometric information).Similarly, the user may update biometric information (e.g., whenpreviously captured biometric information was poor or user biometriccharacteristics have partially changed) by the attestationauthentication procedure and biometric authentication procedure. In thislatter scenario, authentication of biometric information may still beperformed even when the previously captured biometric information waspoor, e.g., by taking multiple biometric samples and/or by using moresophisticated biometric comparison and authentication algorithms. If theuser's biometric characteristic has partially changed, biometricauthentication may still be performed fully or partially based on thebiometric characteristics that has not changed. Once authenticated, theidentity providers may then update and store the updated user biographicand/or biometric data. The provider may further sign the updatedbiographic and/or biometric data and send the signed updated biographicand/or biometric data to the mobile identity wallet of the user. Asanother example, the user may update biographic and/or biometric data ata service provider station. In one implementation, the user may presentidentity data in the mobile identity wallet to the service provider. Theservice provider may validate the user identity following FIG. 9, e.g.,including the identity attestation validation and/or validation of thebiographic and/or biometric information. After the identity validation,the user may be allowed to provide updated biographic and/or biometricdata to the service provider. The service provider may send the updatedbiographic and/or biometric data to the identity provider. The identityprovider may update and store the update user biographic and/orbiometric data and send a signed version back to the user mobileidentity wallet via the service provider.

Turning to FIG. 11, in some implementation, identity of a user may beestablished and verified without a mobile identity wallet. The identityattestation and data element identifier for the identity index dataelement in the permissioned DDSL may only need to be maintained by theidentity provider. The identity provider may then provide a web portalfor the user to log into an identity account maintained by the identityprovider for the user when identity verification of the user by aservice provider is required. The web portal for the user may beaccessed on a web browser running on any data platform. For example, aweb browser may be provided by a service provider station. The webbrowser communicates with web servers of the service provider foraccessing the user identity account. In one alternative implementation,a dedicated application on the service provider station rather than aweb browser may be used for accessing the identity account for the user.FIGS. 11 and 12 illustrate exemplary implementations for creating andaccess user identity without a mobile identity wallet.

FIG. 11 shows an exemplary logic flow 1100 for establishing a useridentity with the identity provider without any mobile device from theuser. Specifically, biographic and/or biometric data of the user arefirst captured by the identity provider station 614 (1102 and 1104). Theidentity provider station communicates with the identity provider server612 for requesting identity enrollment of the user and sends thecaptured biographic and/or biometric information (1106). The identityprovider server 612 performs biometric deduplication upon receiving theenrollment request and biographic and/or biometric information (1108).The identity provider server 512 then sends the deduplication results tothe identity provider station 614 (1110). In the meanwhile, identityprovider server 612 proceeds to create a DUIS for the user and sends theDUIS to the identity provider DDSL node 616 (1112). The identityprovider server 612 further generates a pair of private/public keys forthe user (1114), and sends the generated public key to the identityprovider DDSL node 616 (1116). The private key of the user may bemanaged in an HSM.

Continuing with FIG. 11, the identity provider DDSL node 616 receivesthe DUIS and the user public key, and then generates a token from thereceived DUIS (1118). In an alternative implementation, the token may begenerated by the identity server 612 and then sent to the identityprovider DDSL node. The identity provider DDSL node 616 furthergenerates a data element identifier for an identity index data elementto be inserted into the permissioned DDSL 330/110 (1120). The identityindex data element may contain the token for the DUIP and the public keyof the user. The identity index data element is signed using the privatekey of the identity provider and inserted into the permissioned DDSL330/110 (1122).

Upon creating the data element identifier for the identity index dataelement, a response is sent to the identity provider server 612containing the data element identifier and token for the DUIS (1124).The identity provider 612 then maps the received token and data elementidentifier to the corresponding DUIS of the user (1126). The identityprovider server 612 then proceeds to create an identity attestation(1128). The identity provider server 612 further creates a secure useraccount accessible by the user using, e.g., a set of username andpassword; signs the data element identifier using the private key of theidentity provider; doubly signs the identity attestation (using privatekeys of both the service provider and the user); and securely stores thesigned identity attestation and data element identifier under the secureuser identity account (1130). In one alternative implementation, thedata element identifier may not need to be signed by the identityprovider using its private key. In that implementation, the identityprovider server 612 may store the data element identifier without anydigital signature.

FIG. 12 illustrates an exemplary logic flow for a user to obtain servicevia the user account maintained by the identity provider without amobile identity wallet. Similar to FIG. 9, the first portion of FIG. 12indicated by 1200 illustrates a logic flow for authentication by theservice provider that the digital identity (e.g., the attestation) wasissued and attested to by the identity provider. The second portion ofFIG. 12 indicated by 1201 illustrates a logic flow for furtherverification of the biometric and/or biographic information of the user.As previously discussed, this second portion helps verify that theidentity attestation pertains to the user.

For the first portion of authentication 1200, the user may approach aservice provider station 634 for obtaining service. The user may loginto the user identity account maintained by the identity provider toprovide the signed attestation and the data element identifier for theidentity index data element in the permissioned DDSL for the user (1208and 1210). The user may use, e.g., a web browser provided by the serviceprovider station 634 to log into its identity account.

The service provider station 634 receives the doubly signed identityattestation and the signed or unsigned data element identifier and thensends the data element identifier and identity attestation to theservice provider server and DDSL node 632/636 for authentication (1212).If the data element identifier was not signed by the identity provider,the service provider server and DDSL node 632/636 may directly use theunsigned data element identifier to look up the corresponding identityindex data element in the permission DDSL (1214). In the event that thedata element identifier was signed by the identity provider, the serviceprovider server and DDSL node 632/636 may first use the public key ofthe identity provider to decrypt the signed data element identifier andthen use the decrypted data element identifier to look up thecorresponding identity index data element in the permission DDSL (1214).The service provider server and DDSL node 632/636 may then use thepublic key of the identity provider to decrypt the correspondingidentity data element located and identified from the permission DDSL toobtain the public key of the user (1216). For authentication of theattestation (1218), the public key of the user may be used to decryptthe attestation signed by the user to obtain attestation signed by theidentity provider. The attestation signed by the identity provider maythen be further decrypted by the service provider using the public keyof the identity provider. As such, the identity attestation may be readand analyzed by the service provider to complete the authentication 1218that the content of the identity attestation was indeed signed by theidentity provider and signed by the user. The authentication result isthen sent to the service provider station 634 (1220).

The logic flow 1200 above authenticates that the identity attestationcontains a valid digital signature by the identity provider and theuser. If the service provider desires to further verify that theidentity attestation belongs to the user, logic flow shown in 1201 ofFIG. 12 may be performed. Specifically, the service provider station 634may request permission for further identity verification (1222). Uponsuch a request, the user may give permission via the user identityaccount to the service provider station to verify biographic and/orbiometric data (1224). The permission may be provided in the form aconsent and the consent may be signed by the user using the private keyof the user via the identity account (1226). The signed consent andbiographic data may be sent to the service provider station 634 (1228)and further sent to the identity provider server 612 (1230). Theidentity provider server 612 validates the user consent (1232) bychecking the digital signature on the consent by the user and confirmvalidity of the consent (1234). Upon validity confirmation of theconsent, the service provider station 634 may send user biographic datato the identity provider server for verification (1236). Theverification process by the identity provider server 612 may involvecomparing received biographic data with the biographic data stored inthe identity provider server for the user (1238). Further, the serviceprovider station 634 may physically capture the biometric information ofthe user (1240) and then send the captured biometric data to theidentity provider server 612 (1242). The identity provider server 612then validates the biometric information by comparing the receivedbiometric information with the biometric information stored in theidentity provider server for the user (1244). The validation result maythen be sent to the service provider server 632 and station 634 (1246).

Again, the user consent generated at step 1226 may contain restrictionfor the biographic and/or biometric verification. The consent, forexample, may only be given to biographic data. In anotherimplementation, the consent may restrict the type of biometric databeing taken by the service provider. The consent may further specify anexpiration time of the consent. As such, the identity provider wouldonly perform validation of biographic and/or biometric data if taken andsent by the service provider to the identity provider before theexpiration time.

This second verification process 1201 of FIG. 12 does not involve thepermissioned DDSL. Rather, the verification is performed off-DDSL by theidentity server. Specifically and as described above, the identityprovider server 612 receives the biographic and/or biometric datacaptured by the service provider station 634, and compare the biographicand/or biometric data with the information stored in the identityprovider server under the DUIS corresponding to the token obtained fromthe permissioned DDSL. A match would verify that the identityattestation belongs to the user. The verification outcome may be furthercommunicated from the identity provider server 612 to the serviceprovider off-DDSL (1246).

FIG. 13 further illustrates an example application 1300 of the globalnetwork architecture for a biometric identification described above byfollowing an individual X 1302 through various identity and serviceproviders. Interactions represented by symbol 1340 indicate writes tothe permissioned DDSL 1360 by high trust entities. Interactionsrepresented by symbol 1342 indicate reads from the permissioned DDSL1360 by medium or low trust entities. Activities depicted in row 1350pertain to activities related to the permissioned DDSL. Activitiesdepicted in row 1352 pertain to off-DDSL activities.

Specifically, individual X may go through a biometric enrollment with anentity A 1306 (1304). Entity A issues an identity to individual X andinsert an identity index data element into the permissioned DDSL (1308).The data element functions as an identity index for the purpose ofidentity authentication as described in the implementations above. Theidentity index data element does not contain actual biographic orbiometric information. Rather, these data are secured maintained byentity A off-DDSL (1314). Entity A further perform de-duplication ofbiographic and/or biometric information off-DDSL to avoid multipleregistration for the same individual X (1314). The identity ofindividual X is registered on smart phone or other mobile device 1310 ofindividual X (1312). Once registered, individual X may visit a certifiedservice provider, such as hospital 1316 to access healthcare servicesthat require identity verification (1314). Hospital 1316 may read theidentity index data element for individual X from the permissioned DDSLto authenticate the identity carried in the mobile phone of individual X(1318). Healthcare services may be provided accordingly afterauthentication. Hospital 1316 may not require physical verification ofbiometric information.

Continuing with FIG. 13, individual X may travel to enter country B1322, which require both identity authentication and biometricverification (1320). Country B may read the identity index data elementof individual X from the permissioned DDSL for identity authentication(1324). Country B may also be an identity provider and thus may capturebiographic and/or biometric information of individual X, performdeduplication, and store the de-duplicated information off-DDSL (1328).Country B may be of high level of trust and may thus write a newidentity index data element into the permissioned DDSL representingidentity registration of individual X in country B, or concerning theentry of individual X into country B (1326). Country B may furtherupdate the mobile phone of individual X concerning this identityregistration in country B. Country B may perform biometric verificationby requesting entity A to match the biometric information captured bycountry B and the biometric information stored with entity A whenindividual X's identity was registered by entity A (1330). Individual Xmay further go to open a bank account with bank 1334 using its digitalidentity (1332). The bank 1334 may read the permissioned DDSL foridentity index data elements written by entity A and country B foridentity authentication before proceeding to open a bank account forindividual X (1336).

The global network architecture and system for biometric identificationdescribed above and implemented by the system circuitry 404 of FIG. 4 ofvarious servers, stations and DDSL nodes improve the functioning of theunderlying hardware itself, by implementing a non-traditional andpermissioned DDSL for storing unalterable identity indexes incombination with off-DDSL secure storage of biometric information toachieve portable electronic identity. Such a system uses DDSL to protectthe authenticity of the identity registration and controls access tobiometric information at the same time. As a few examples of improvedfunctionality described in FIGS. 5-13, the system circuitry 404provides: biometric data capture, biographic data capture, securebiometric and/or biographic data storage, obtaining DUES, tokengeneration from DUES, de-duplication of individual identities, creatingencryption keys for digital signatures, issuing use consent requests andreceiving consent authorization messages, biometric data retrieval fromthe data storage layer, biometric data verification, permissioned DDSL,and an interplay between DDSL functionalities and off-DDSLfunctionalities. These functions may be distributed over multiplephysically distinct and connected data platforms, and need not all bepresent within a single system. The distributed data platforms arearranged and interact in a specific way to function as a globalbiometric identity registration, authentication, and verification systemin the context of providing and receiving a range of services requiringvarious levels of identity verification.

The system provides technical solutions to the problems associated withphysical identity. Such problems include the dedicated infrastructureneeded to enroll and vet residents and provision identity documents;that such an infrastructure and identity documents are costly; thatpossession of physical documents may not require demonstration of a linkbetween an individual and the documents; that they can be falsified,altered or tampered with, as well as lost or stolen; and the potentialfor human error in creation of the documents and transactions using thedocuments. The biometric processing system described above, for example,links individuals to a digital identity as shown in FIGS. 5 and 13. Notethat the data storage layer based on a permissioned DDSL, e.g., aconsortium-based and permissioned distributed ledger, allows individualsto control their accredited identity index, making it unalterable andavailable to certified entities globally. In some of the implementationsabove (e.g., FIGS. 11 and 12), a need for any physical identity ordigital identity device is removed. Moving physical or portable digitalidentity device into the network provides improved mobility andrepresents a technical solution to the problems above.

The system disclosed above has many data access advantages, e.g., thesystem:

-   -   allows individuals to manage who has access to their data, down        to the specific fields and time allowed to access the data;    -   allows the individual to establish relationship with trusted        parties via explicit consent;    -   provides the flexibility to extend the scope of the solution to        allow an individual to share data in circumstances where        participants cannot share data with another party due to        national and regulatory jurisdiction; and    -   provides easier compliance with data protection regulations        (such as General Data Protection Regulation of European Union)        and other similar regulations.

Other additional benefits and characteristics of the system disclosedabove include that the system:

-   -   links digital identity to a real person; Reduce fraud;    -   increases non-repudiation through the use of biometric        de-duplication;    -   enables portable identity with no need for documents;    -   reduces the number of duplicates of identities in system;    -   returns ownership of data back to user;    -   stores proofs of unique identity on DDSL and can be accessed by        others on the chain;    -   removes the need to repeat de-duplication or conduct biometric        identity proofs if capture/enrolment party is high        assurance/trust.

The methods, devices, architectures, processing, circuitry, and logicdescribed above may be implemented in many different ways and in manydifferent combinations of hardware and software. For example, all orparts of the implementations may be circuitry that includes aninstruction processor, such as a Central Processing Unit (CPU),microcontroller, or a microprocessor; or as an Application SpecificIntegrated Circuit (ASIC), Programmable Logic Device (PLD), or FieldProgrammable Gate Array (FPGA); or as circuitry that includes discretelogic or other circuit components, including analog circuit components,digital circuit components or both; or any combination thereof. Thecircuitry may include discrete interconnected hardware components or maybe combined on a single integrated circuit die, distributed amongmultiple integrated circuit dies, or implemented in a Multiple ChipModule (MOM) of multiple integrated circuit dies in a common package, asexamples.

Accordingly, the circuitry may store or access instructions forexecution, or may implement its functionality in hardware alone. Theinstructions may be stored in a tangible storage medium that is otherthan a transitory signal, such as a flash memory, a Random Access Memory(RAM), a Read Only Memory (ROM), an Erasable Programmable Read OnlyMemory (EPROM); or on a magnetic or optical disc, such as a Compact DiscRead Only Memory (CDROM), Hard Disk Drive (HDD), or other magnetic oroptical disk; or in or on another machine-readable medium. A product,such as a computer program product, may include a storage medium andinstructions stored in or on the medium, and the instructions whenexecuted by the circuitry in a device may cause the device to implementany of the processing described above or illustrated in the drawings.

The implementations may be distributed. For instance, the circuitry mayinclude multiple distinct system components, such as multiple processorsand memories, and may span multiple distributed processing systems.Parameters, databases, and other data structures may be separatelystored and managed, may be incorporated into a single memory ordatabase, may be logically and physically organized in many differentways, and may be implemented in many different ways. Exampleimplementations include linked lists, program variables, hash tables,arrays, records (e.g., database records), objects, and implicit storagemechanisms. Instructions may form parts (e.g., subroutines or other codesections) of a single program, may form multiple separate programs, maybe distributed across multiple memories and processors, and may beimplemented in many different ways. Example implementations includestand-alone programs, and as part of a library, such as a shared librarylike a Dynamic Link Library (DLL). The library, for example, may containshared data and one or more shared programs that include instructionsthat perform any of the processing described above or illustrated in thedrawings, when executed by the circuitry.

Various implementations have been specifically described. However, manyother implementations are also possible. For instance, any of thecomponents and functionality in the architecture may be hosted invirtual machines managed by a cloud services provider. That is, whilesome implementations may be completely localized within a givenenterprise, other implementations are completely migrated into thecloud, or are hybrid implementations with mixed local and cloudimplementation. Regarding querying devices, the smartphones applicationsand desktop computers noted above are just particular examples, andother querying devices may be used, including hands-free systems invehicles, digital personal assistants in smartphones or desktop PCs,hands-free control systems for the home, and many other types ofdevices.

What is claimed is:
 1. A system comprising: a distributed ledger datastorage layer comprising a first circuitry; and a service access nodefor accessing the distributed ledger data storage layer comprising asecond circuitry, wherein the first circuitry is configured to: providea first permissioned access associated with a first higher access levelto the service access node for storing an identifier of a digitalidentity in a linked chain of non-alterable data blocks in thedistributed ledger data storages layer; and provide a secondpermissioned access associated with a second lower access level to aserved access node to authenticate the identifier of the digitalidentity with the linked chain of non-alterable data blocks in thedistributed ledger data storages layer; and wherein the second circuitryis configured to: provide the served access node an authentication ofthe digital identity associated with the authenticated identifier viacommunications offline with the distributed ledger data storage layerbetween a server associated with the service access node and a serverassociated with the served access node.
 2. The system of claim 1,wherein the second circuitry is configured to store the digital identityoff the distributed ledger data storage layer in the server associatedwith the service access node.
 3. The system of claim 2, wherein thedigital identity comprises a human biological identity.
 4. The system ofclaim 3, wherein the human biological identity comprises at least one offingerprint, retina image, iris image, facial image, voice sample, DNAsequence, palm vein image, and palm print identity.
 5. The system ofclaim 3, wherein the human biological identity is captured by a servicestation associated with the service access node.
 6. The system of claim5, wherein the second circuitry is configured to provide the servedaccess node the authentication of the digital identity by comparing thehuman biological identity captured by the service station and anotherbiological identity captured by the served access node.
 7. The system ofclaim 1, wherein the identifier of the digital identity comprises atoken of an identification sequence generated using a one-way functionfrom the digital identity and a public key associated with the digitalidentity.
 8. The system of claim 7, wherein the first circuitry isconfigured to provide the second permissioned access to the servedaccess node to authenticate the identifier of the digital identity by:receiving the identifier from the served access node; receiving adigital identity attestation digitally signed by the server associatedwith the service access node; obtaining an index corresponding to theidentifier received from the served access node; requesting andreceiving a second identifier from the distributed ledger data storagelayer queried under the index; and authenticate the identifier byverifying the digital identity attestation and based on a comparison ofthe identifier and the second identifier.
 9. The system of claim 8,wherein the served access node is configured to communicate with amobile identity wallet presented by a holder to obtain the identifierand attestation.
 10. The system of claim 9, where the public keyassociated with the digital identity is generated by a mobile devicehosting the mobile identity wallet.
 11. The system of claim 10, wherethe digital identity attestation generated and signed by the serverassociated with the service access node is further signed by the mobiledevice.
 12. A method comprising: providing a first permissioned accessassociated with a first higher access level to a service access node forstoring an identifier of a digital identity in a linked chain ofnon-alterable data blocks in a distributed ledger data storages layer;providing a second permissioned access associated with a second loweraccess level to a served access node to authenticate the identifier ofthe digital identity with the linked chain of non-alterable data blocksin the distributed ledger data storages layer; and providing the servedaccess node an authentication of the digital identity associated withthe authenticated identifier via communications offline with thedistributed ledger data storage layer between a server associated withthe service access node and a server associated with the served accessnode.
 13. The method of claim 12, further comprising storing the digitalidentity off the distributed ledger data storage layer in the serverassociated with the service access node.
 14. The method of claim 13,wherein the digital identity comprises a human biological identity. 15.The method of claim 14, wherein the human biological identity comprisesat least one of fingerprint, retina image, iris image, facial image,voice sample, DNA sequence, palm vein image, and palm print identity.16. The method of claim 14, wherein the human biological identity iscaptured by a service station associated with the service access node.17. The method of claim 16, wherein providing the served access node theauthentication of the digital identity comprises comparing the humanbiological identity captured by the service station and anotherbiological identity captured by the served access node.
 18. The methodof claim 12, wherein the identifier of the digital identity comprises atoken of an identification sequence generated using a one-way functionfrom the digital identity and a public key associated with the digitalidentity.
 19. The method of claim 18, wherein providing the secondpermissioned access to the served access node to authenticate theidentifier of the digital identity comprises: receiving the identifierfrom the served access node; receiving a digital identity attestationdigitally signed by the server associated with the service access node;obtaining an index corresponding to the identifier received from theserved access node; requesting and receiving a second identifier fromthe distributed ledger data storage layer queried under the index; andauthenticate the identifier by verifying the digital identityattestation and based on a comparison of the identifier and the secondidentifier.
 20. The method of claim 19, wherein the served access nodeis configured to communicate with a mobile identity wallet presented bya holder to obtain the identifier and attestation.